incidents: add INC-132, Deadbugz MCP call-count-gated tool poisoning - #109

Thanks for this — the record is careful work, and the call-count gating detail is a genuinely useful thing to have in the index.

Two things, one of them my fault.

1. INC-132 is already taken. It was allocated by #117 (merged ea971a0) for the Agno RCE CVE while this PR was open — that's an id-allocation race, not anything you did wrong, and GitHub is already reporting this branch as conflicting. Could you renumber and rebase?

The next free id is INC-136: main holds INC-001…INC-134, and INC-135 is claimed by open PR #122 (llmware SQLi). If #122 lands after you, you'd collide again — so #136 is the safe pick either way.

Happy to do the renumber and rebase for you if you'd rather not — say the word and I'll push it to your branch, or open a follow-up that does it, whichever you prefer. Only asking first because it's your branch.

I'm also adding a guard so this can't recur: a validator check that fails on duplicate incident ids, plus a scripts/next-incident-id.mjs helper so contributors can allocate an id without reading the whole file. That's in a separate small PR and will land independently of this one.

2. Triage verdict: it qualifies. I checked it against docs/TRIAGE_RULES.md, which restricts the incident index to real-world deployment failures and routes laboratory work elsewhere. Deadbugz clears that bar: a malicious MCP server was actually published, and 23 PRs were actually opened against unrelated repositories by a named account. Those are artifacts deployed in the wild, not a proof of concept — so it belongs in the index rather than in the benchmark catalogue or a close-as-noted.

One thing worth a second look while you're rebasing: the record sets category: "real-world" but its own impact says "no confirmed compromise as of disclosure". Both readings are defensible — the campaign is real, the victim impact is unconfirmed — but research-demonstrated may fit better, and either way it's worth being deliberate about. Entirely your call; I'm not going to touch it.

Nothing else blocks this from my side.

Thanks for catching both. Pushed a fix for each.

Renumbered to INC-136 and rebuilt clean off current main. #117 and #122 both touch the same generated JSON/JS this schema regenerates, and a hand-resolved merge there risked corrupting it. Checked the free id against main directly: 001 through 134 contiguous, 135 claimed by your open #122, so 136 stays clear either way that one lands.

On category, I went with your suggestion, research-demonstrated. Wanted to write down why it's right, since I checked it rather than took it on faith. The schema's own enum description defines real-world as a confirmed incident, and this entry's impact field says plainly that no compromise was confirmed, 23 delivery PRs, none merged. INC-126 is the only other entry in the dataset with comparable unconfirmed-impact language, and it already carries research-demonstrated. Three independent readings landing on the same answer is what convinced me.

One small thing on your review: I couldn't find docs/TRIAGE_RULES.md anywhere in the repo, on main or any open PR. Not blocking anything here, the schema enum backs the same verdict on its own. Flagging in case it's sitting uncommitted somewhere on your end.

Thanks — both changes check out, and the category reasoning from the schema enum is the right basis.

You're right about docs/TRIAGE_RULES.md, and that's my error. The file is added by #121, which hasn't merged yet; I linked it as if it were on main. Until #121 lands, the text is at docs/TRIAGE_RULES.md on the #121 branch. Sorry for sending you looking.

Verification of this branch (d9d3394):

• On its own against current main: validate 0 errors, stats:check current, 85/85 unit tests, and a fresh generate.js reproduces your generated files exactly (no drift).
• Every factual claim in INC-136 matches the Pillar post (published 2026-08-12): 23 PRs from zellkernel, 21:52–23:07 UTC on 2026-08-10, 19 closed / 4 open / none merged, the three-call threshold on tools/list and prompts/get, the four credential targets plus concealment, productivity-suite with format_text / summarize, and no confirmed victim.

One non-blocking suggestion. The convention for control_failures.basis is a sentence quoted from the source, so a reviewer can confirm it without re-deriving it. The current basis is an accurate paraphrase. Pillar has a sentence that says the same thing:

"The three-call threshold acts as research evasion, allowing a brief inspection or limited automated test to receive only benign metadata before the server exposes the instructions presented to the agent."

Swapping it in is your call. Either way, the failure stays a draft (confirmed_by empty) until an SME confirms it, like every other drafted control failure in the index.

Merge-order note, so you aren't surprised later. This PR and #122 (INC-135) each add an incident and regenerate the same files (data/stats.json, README.md stats, docs/incidents.js). They merge without textual conflict, but whichever lands second leaves those counts one short: 2 unit tests fail (136 !== 135) until generate.js + npm run stats + render-stats.mjs are re-run. I checked this. After the regenerate, the full stack is green (0 errors, 89/89). #122 also adds two optional fields (incident_class, mapping_status). INC-136 validates without them, and whether a campaign like this is tooling-cve or ai-behaviour is a classification I'd rather leave to the maintainer than set for you.

CI hasn't run here. Workflows on fork PRs wait for a maintainer to approve them, so the green results above are local runs, not GitHub checks.

Steps for you to merge main and regenerate — no action needed after all. This PR was merged before my comment went up, so I've applied the same regenerate and tag removal on main in #178. Thanks again for the careful record, @gautamgb.